ProjectManagement

• 소프트웨어 프로젝트 관리

  • 프로젝트 관리란 무엇인가?
  • 프로젝트 계획
  • 프로젝트 비용 추정
    • 기능 점수(Function Point)
    • COCOMO

• 프로젝트 제어 기법

  • 작업 분할 구조(Work Breakdown Structure, WBS)
  • 간트 차트(Gantt Chart)
  • PERT 차트(프로그램 평가 및 검토 기법, Program Evaluation and Review Technique)

• 프로젝트 팀 조직

• 리스크 관리

• 프로젝트 관리 계획

Intro

소프트웨어 프로젝트 실패의 원인

• Lack of SW mind
  • 나중에 변경 사항이 있어도 SW는 쉽게 바꿀 수 있겠지
• 적절한 소프트웨어 엔지니어링 스킬 부족
• 소프트웨어 프로젝트 관리 부족

소프트웨어 프로젝트에서 관리해야 할 이슈

• 스케줄 관리
• 사람 관리
• 리스크 관리
• 재사용성 관리

Project Management

필요성

• 비효율적인 관리로 인한 프로젝트 실패
• 프로젝트 지연
• 신뢰성 저하
• 예산 초과
• 성능 저하

다른 공학과의 차이점

• 제품이 무형
• 소프트웨어 프로세스를 명확히 이해하지 못함
• 제조 집약적이 아닌 설계 집약적임
  • 사람의 능력에 의존

성공적인 소프트웨어 프로젝트의 가장 중요한 요인

• "도구가 아닌 사람이 중요하다"
• "똑똑한 사람을 가지는 것 외에는 거의 중요하지 않다."
• "내 관리의 유일한 규칙은 좋은 사람을 확보하는 것이다."

Management Function(관리 기능)

관리의 정의

• 개인들이 그룹으로 협력하여 효율적이고 효과적으로 그룹 목표를 달성할 수 있는 내부 환경의 생성 & 유지
• 관리의 일반 기능
  • 계획: 목표, 자원, 정보 흐름, 사람, 산출물
  • 조직화: 그룹에 대한 권한과 책임
  • 인사 관리: 인원 채용
  • 지휘: 부하 직원 지도
  • 통제: 활동 측정 및 수정

Management Steps(관리 단계)

• 프로젝트 진행 상황 점검
• 계획과의 차이를 처리하기 위한 조치

1. 계획
   • 목표 이해 및 문서화
   • 스케줄, 예산 및 기타 자원 요구사항 개발
2. 자원 확보
   • 공간, 컴퓨팅 자원, 자료 및 인적 자원
3. 계획 실행
   • 계획을 실행에 옮기기
4. 모니터링
   • 진행 상황 확인
   • 편차가 발생하면 어떤 액션을 할것인가

프로젝트 계획**

계획 이슈

• 가정, 목표, 제약 조건을 명확히 정의하고 문서화
• 필요 자원과 예산 결정
  • 사람의 수와 기술 수준
  • 컴퓨터 자원의 양(SW Tools도 포함)

계획에서의 예측

• 필요한 엔지니어 수
• 소프트웨어 엔지니어의 생산성
  • 생산성은 일정기간 동안 얼마나 처리하는가를 말함
• =>소프트웨어 비용 평가

소프트웨어 생산성

프로젝트 계획에 필요한 것

• 작업 난이도를 추정
• 각 엔지니어가 해결할 수 있는 작업의 양을 추정

생산성 측정 지표

• 기능의 양
• LOC(코드 라인 수)
  • 이상적인 생산성 지표는 아님

기능성 정량화

• 기능 점수(Function Points)

LOC(Line Of Code)(라인코드수)

• 생산성을 측정에 가장 일반적으로 사용되는 지표
• 문제가 많지만 측정이 쉬움
• 현재는 유용하지 않지만 참고용으로 사용

가장 일반적인 코드 크기 측정 두 가지:

• DSI(제공된 소스 명령어)
  • 고객에게 전달된 코드 라인만 포함
  • 주석 포함
  • 많이 씀
• NCSS(비주석 소스 문장)
  • 주석 라인은 제외

Function Points(기능점수)

• 소프트웨어 시스템의 기능을 정량화하려는 시도
• 시스템의 복잡성을 특징화
  • 얼만큼 복잡한 SW인가

예측할 때 필요한것

• 얼마나 걸리는가
• 얼마나 사람이 필요한가

Function Points 특징

• 정보 처리 애플리케이션에 적합
• 생산성, 비용, 오류 수를 측정할 수 있음
• 미래 계획의 기초로 사용될 수 있음
• 다양한 언어의 상대적인 효율성 측정
• 해결할 문제가 많아 기대치에 미치지 못함

현재 요구사항으로 예측하기 때문에 딱 맞는다는 보장이 없음
미래의 변경사항은 모르기 때문에
하지만 더 현실적임
$1FP\approx c언어132줄\approx Java53줄$

일반 소프트웨어 시스템의 기능

• 소프트웨어 시스템
  • 내부 논리 파일
  • 사용자 외부 입력
  • 사용자 외부 출력
  • 외부 질의
  • 사용자 외부 시스템 인터페이스
• 데이터 기능(중요)
  • 내부 논리 파일 + 외부 인터페이스 파일
• 트랜잭션 기능(중요)
  • 외부 쿼리 + 외부 출력 + 외부 입력

FP 분석 방법

1. 프로젝트 유형 결정
2. 대상 시스템 범위 결정
3. 데이터 기능 식별 및 복잡성 결정
4. 트랜잭션 기능 식별 및 복잡성 결정
5. 비조정 FP 산출
   • 3번 + 4번
6. 가치 조정 계수 결정
7. 조정된 FP 산출
   • 초기 기능 점수 * 조정값

FP 분석 방법 각 단계 활동

1. 프로젝트 유형 결정

   • 신규 프로젝트, 유지보수 프로젝트, 개선 프로젝트

2. 대상 시스템 범위 결정

   • 전체 혹은 일부, 내부 개발, 외주, 패키지 획득 등

3. 데이터 기능 및 복잡성 식별

   • 데이터 기능 복잡성 계산 행렬
     • 
   • 데이터 기능 기여도 행렬
     • 

4. 트랜잭션 기능 및 복잡성 식별

   • 예시: 외부 입력에 대한 복잡성 행렬
     • 
   • 외부 입력 기여도 행렬
     • 
   • 외부 입력, 외부 쿼리에 대한 복잡성 행렬
     • 
   • 외부입력, 외부 쿼리 기여도 행렬
     • 

5. 비조정 FP 산출

   • UFP = 모든 기능에 대한 가중치 합계
     • 

6. 가치 조정 계수(VAF) 결정

   • 
     • TDI = Total Degree of Influence
       • 총 영향 수치

7. 조정된 FP 산출

   • Adjusted Function Point
   • **AFP = UAF * VAF **

프로그래밍 언어별 LOC와 FP

생산성에 영향을 미치는 기타 요인

• 인원 역량
• 제품 복잡성:
• 요구 신뢰성
  • 실시간 시스템에서 타이밍 제약
• 일정 제약
• 언어 경험
• 인력 이동
• 시스템 재구성
• 등

소프트웨어 비용 추정 기법

알고리즘 기반 비용 모델링

• COCOMO, COCOMO II

전문가 판단

• Delphi Method
  • 전문가 지식을 통한 문제해결, 예측 기법

유사 추정

• 유사 프로젝트에 의한 추정

파킨슨 법칙

• 사용 가능한 자원에 의해 결정

하향식 추정

• 전체 기능을 처음으로

상향식 추정

COCOMO 모델

제안자

• 1981년 B. Boehm

기반

• 전달된 소스 명령어(KDSI)
• 복잡성과 세부 사항 레벨을 높이는 3개의 다른 모델

명목상 노력 및 일정 방정식:

개발 모드

• 유기적(Organic)
• 반독립적(Semidetached)
• 내장형(Embedded)

명목상 노력

• PM
  • Person(programmer)-Month
  • 한 사람이 한 달 동안 일할 수 있는 양
• KDSI
  • 프로젝트 코드 크기 측정 단위
  • 1 KDSI = 1000줄

일정

• TDEV
  • Month required to complete the project
  • 프로젝트를 완료하는데 요구되는 기간(개월)
• $P{M}_{DEV}$
  • PM * Effort multiplier

Effort Multiplier(노력 배율)

• 15개 요인(시스템 특성)의 곱을 통해 계산됨.

민감도 분석

• 노력 배율에서 파라미터를 바꿈으로써 민감도 분석 가능

COCOMO II와 차이점

• 프로세스 모델에 대한 가정
  • COCOMO: 순차적 개발 프로세스(폭포수 모델)
    • 이미 계획한 것에 대해서만 예측이 가능
  • COCOMO II: 반복적 접근 방식, RAD, 재사용 기반 접근 등
    • 변경에 대해서 어느정도 예측이 가능하다는건가?
• 추정 방식
  • COCOMO: 소스 길이(KDSI) 사용
  • COCOMO II: 소스 길이 및 기능 점수 사용

COCOMO II

3가지 모델

• Application point(App.point)
  • # of componets, # of screens in input / output interface
    • 화면이 몇개 나오느냐

Project Control(프로젝트 제어)

• 활동 진행을 모니터링
• 계획과의 차이를 감지
• 프로젝트 제어 기법
  • 작업 분할 구조(WBS)
  • 간트 차트
  • PERT 차트
  • Kanban board

이미 경험한 프로젝트 => 잘 알고있기 때문에 요구사항 분석 시간이 줄임
요구사항 분석에서 같은 퀄리티에 적게 걸리면 좋고 더 걸리
대안이 필요

프로젝트 제어 기법

• 작업 분할 구조 (WBS)
• 간트 차트
• PERT 차트

WBS (작업 분할 구조)

• 프로젝트 목표를 여러 중간 목표로 분할

WBS 목표

• 프로젝트가 수행해야 하는 모든 활동을 식별

구조

• 프로젝트 주요 활동을 루트로 하는 트리
• 작은 컴포넌트로 분할
• 트리의 리프는 작업의 한 조각
• 매니저가 직관적으로 사이즈, 어려움, 자원을 고려하고 확신하는 정도까지 쪼갬

사용되는 곳

• 프로젝트 계획 요약
• 일정 과정으로의 입력

Example of WBS

Gantt Chart(간트 차트)

• 일정, 예산, 자원 계획을 위한 기법

구조

• 각 바는 활동을 표현
• 각 활동을 시간을 기준으로 시각화
• 바는 개발 시간에 길어지고 짧아짐

특징

• 리소스 할당 및 인력 계획에 유용
• 작업간 의존성 하이라이트X

Example of Gantt chart

• Slack time
  • 가장 늦게까지 언제 끝나는가
• 바가 겹치지 않는 활동에 대해서 같은 사람에게 맡길 수 있음

PERT Chart(PERT CPM Chart)

• Program Evaluation and Review Techniques = PERT-CPM
• Critital Path Methjod(임계 경로), CPM(중요)
  • 중요한 정보 제공

활동들의 의존성 표현

• network = 다이어그램
• 활동 => box or circle
• 화살표 => 의존성

현저한 특징

• 평행성을 모두 보여줌
• 대체 스케줄의 스케줄링 및 시뮬레이션 허용
• 매니저가 프로젝트를 모니터링하고 제어할 수 있도록 지원

Dates from PERT chart

• 빠른 시작 및 늦은 시작, 빠른 종료와 늦은 종료 날짜 표시

임계 경로

• 프로젝트 전체 지연을 유발할 수 있는 경로
• 

Kanban Board(칸반 보드)

• 작업을 시각화하고, 진행 중인 작업을 제한하며, 효율성을 극대화를 위한 관리 도구
• 진행 중인 작업을 표시하여 병목 현상과 과도한 작업 할당을 식별하는 시각화 도구

칸반의 기원

• 도요타 칸반 시스템 for JIT production (1963년)
  • 로지스틱스, 공급자 관리, 고객 배송 등 제조 작업을 조직하는 데 사용

응용 분야

• 애자일 및 DevOps 팀이 일상적인 작업에서 질서를 잡기 위해 사용
• 마케팅 팀, 인사 팀, 개인 칸반 등 다양한 부서에서 활용

Example of Kanban Boadrd

• JIRA같은 도구를 통해 디지털 형식으로 구현 가능
  

계획과의 차이점에 대한 대처

일정과 편차가 발생했을 때 관리자의 대처

• 엔지니어 추가X But 적절한 엔지니어라면 추가
• 일시적으로 시니어 엔지니어 재배치 또는 고급인력인 문제 해결 컨설턴트 고용
• 요구 사항 스크러빙
• 원래 계획 및 일정의 오류 인정
• 지연을 최선의 조치로 수용

팀 조직화

목표

• 공동 목표를 향한 협력 촉진

조직 구조 종류

• 중앙 집중형 구조
• 분산형 구조
• 하이브리드 구조
• 그 외 기능 지향, 프로젝트 지향, 매트릭스 구조 등

조직 구조 유형을 정하는 요소

• 프로젝트 길이
• 어떤 작업인지
• 커뮤니케이션이 얼마나 필요한지
• 팀이 적절한 크기인지

조직 구조

중앙 집중형 팀

• 소규모 또는 단기 프로젝트에 유용
• 주 프로그래머 팀
• 주 프로그래머(프로젝트 매니저)가 프로젝트의 설계와 기술적 세부 사항을 책임짐
• 작업이 명확히 이해될 때 효과적임
• 주 프로그래머가 과도한 업무를 맡게 될 수 있음
  

분산 제어 팀

• 민주적인 팀 구조
• 합의를 통해 결정
• 서로의 작업을 검토
• 높은 의욕과 낮은 이직률 유도
• 장기 프로젝트에 적합
• 잘 이해되지 않았거나 복잡한 문제에 적합 => 논의를 통해 해결이 가능함
• 큰 팀에는 부적합 => 커뮤니케이션이 너무 오래 걸림
  

혼합 제어(하이브리드) 팀

• 계층적 팀 구조
• 중앙 집중식 팀과 분산 제어 팀의 결합
• 두 구조의 장점 모두 가짐
• 큰 규모 프로젝트에 적합
  

팀 조직의 평가

• 모든 작업에 적합한 팀 조직은 없음
• 엔지니어 간 의사소통이 필요한 경우에는 분산 제어가 최선
• 개발 속도가 가장 중요한 목표이고 문제가 명확히 이해될 때는 중앙 집중식이 최선
• 필요한 의사소통 양으로 제한
• 개발 속도 이외의 목표 고려:
  • 낮은 생명 주기 비용
  • 인력 퇴사 감소
  • 주니어 엔지니어 양성
  • 특수 지식 및 전문성의 폭넓은 전파
    

위험 관리

소프트웨어 엔지니어링에서 일반적인 위험 관리

• 요구사항 변경
• 프로젝트에 적합한 인력이 없을 경우

위험 감소 방법

• 프로토타이핑
• 점진적 전달
• 모듈형 설계
  • 변경에 쉽게
  • 기능을 잘 분할, 정의, 매칭

위험 관리 양식 예시

소프트웨어 엔지니어 영역에서 일반적인 위험

• 인력 부족

  • 우수 인재 채용, 업무 매칭, 팀 빌딩, 주요 인력 계약, 교차 교육, 주요 인력 사전 스케줄링

• 비현실적인 일정 및 예산

  • 다중 소스 비용 및 일정 추정, 점진적 개발, 소프트웨어 재사용, 요구 사항 정리

• 잘못된 소프트웨어 기능 개발

  • 조직 분석, 미션 분석, 운영 개념 공식화, 사용자 설문 조사, 프로토타이핑, 초기 사용자 매뉴얼

• 골드 플레이트 (불필요한 기능 추가)

  • 요구 사항 정리, 프로토타이핑, 비용 대비 효과 분석, 비용에 맞춘 설계

• 계속적인 요구 사항 변경

  • 높은 변경 임계값, 정보 은닉, 점진적 개발(변경 사항을 후속 단계로 연기)

SPMP (소프트웨어 프로젝트 관리 계획) 내용

1. 소개

   • 문서의 목적
   • 프로젝트 개요
   • 관련 문서, 용어, 약어

2. 개발 계획

   • 자원: 인력, 비용
   • 작업 분할 구조(WBS)
   • 일정 (간트 차트)

3. 조직

   • 팀 구조
   • 역할 및 책임

4. 기술 관리

   • 변경 관리
   • 구성 관리
   • 기술 관리

5. 품질 관리

   • 검토 방법
   • 검토 주기
   • 기타 품질 관리 기술

6. 개발 환경

   • 필요한 소프트웨어 및 사양
   • 하드웨어 사양
   • 공간 및 보안
   • 기타 사항

7. 산출물

   • 문서 정의
   • 배포 날짜와 목적지

8. 기타

   • 고려할 문제들

9. 참고 문헌 및 부록

문서 내용은 조직의 표준에 따라 다를 수 있음

요약 및 토론

• 프로젝트 관리 단계

  • 계획 → 자원 확보 → 실행 → 모니터링

• 소프트웨어 생산성 (또는 규모) 추정

  • LOC, FP(기능 점수)

• 프로젝트 제어 기법

  • 작업 분할 구조(WBS), 간트 차트, PERT 차트

• 팀 조직

• 프로젝트 위험 관리

효과적인 프로젝트 관리가 소프트웨어 품질을 개선할 수 있는가?